namespace Adoor.Object
{
#if DEBUG
	/// <summary>
	/// Adoor.NET is composed of several independant aspects:
	///
	/// <ul><li><p><b>Domain and Query aspects</b></p>
	/// <p>Regardless of how they are implemented, queries can be performed over objects.</p>
	/// <p>This implies that objects and their relationships are precisely described in a domain model
	/// (namespace <see href="Adoor.Object.Domain.html">Adoor.Object.Domain</see>) and that queries can be
	/// composed and checked against the domain model (namespace <see href="Adoor.Object.Query.html">Adoor.Object.Query</see>).
	/// Precisely, how a query is to be executed is out of the scope of this aspect (though the semantics of the operators ARE in
	/// this scope).</p>
	/// <p>The query language is inspired by the relational theory and includes operators like join and project. This means that
	/// <ul><li>some queries (those that do not contain joins and projects) may return collections of objects</li>
	/// <li>some queries (in the more general case) may return raw data (represented as DataSet or DataReader objects), not in a
	/// direct one to one correspondance with the classes of the domain model. Though a natural part of every relational tool,
	/// this is an oft-missed feature in other object-querying tools.</li></ul></p></li>
	///
	/// <li><p><b>Disconnected aspect</b></p>
	/// <p>The repository where the objects ultimately reside generally is not the application's memory itself, but an external
	/// storage like a DBMS.
	/// This implies that there is a boundary to cross in order to access data. Since this boundary crossing has a cost,
	/// Adoor.NET provides mechanisms to help developers optimize boundary traversals:
	/// (namespace <see href="Adoor.Object.Disconnected.html">Adoor.Object.Disconnected</see>)</p><ul>
	/// <li>the remote (out of process) source can be queried directly, which provides best performances in one-shot, read-only
	/// scenarios</li>
	/// <li>a local (in-process) storage is used as a cache to store new and modified data</li>
	/// <li>the local storage can be queried too</li>
	/// <li>an "objet context" provides the glue between the remote source and the local storage</li>
	/// <li>in particular, the object context can be used to preload in bulk mode the local cache with data from the remote
	/// source</li></ul>
	/// <p>Combining the preloading facilities with the query-language-with-joins is part of the anwser to overcome performance
	/// issues generally associated with object persistence layers.</p></li>
	///
	/// <ul><li><p><b>Entity aspect</b></p>
	/// <p>Queries that return collections of objects store those object in a local storage. This is the entity aspect
	/// (namespace <see href="Adoor.Object.Entity.html">Adoor.Object.Entity</see>).</p></li></ul>
	/// <li><p><b>Relational aspect</b></p>
	/// <p>A RDBMS is one possible implementation of an external storage. Great care has been taken to decouple this aspect from the other ones,
	/// so that relational persistence is not the only possible option, and that the queryable and disconnected aspects can be reused in other
	/// scenarios.</p>
	/// <p>The O/R mapping (<see href="Adoor.Object.Relational.html">Adoor.Object.Relational</see>) leverages a database-independant API (Adoor.Relational) which allows to compose
	/// relational queries (different from object queries) out of relational operators and to generate the corresponding SQL based on
	/// drivers targeting particular RDMS engines.</p>
	/// <p>The O/R mapping is extensible : it is based on factory classes that are declared and configured in a XML file.</p></li></ul>
	/// </summary>
	public class NamespaceDoc
	{
	}
#endif
}
